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Real Party in Interest 

The subject patent application is owned by International Business Machines Corporation 
of Armonk, NY. 



Related Appeals and Interferences 

None. 



Status of Claims 

On September 25, 2003, appellant appealed from the final rejections of claims 1 - 39. 

Status of Amendments 

The claims were amended from their originally-filed states in a reply to non-final 
rejections, filed by the applicant on May 23, 2003. The amendment was apparently entered, as 
the next Office Action addressed the merits of the changes. 

Appellant filed an amendment making a minor correction to Claim 1 concurrently with 
Notice of Appeal in order to correct a double-word typographical error, to place the claims in 
better condition for consideration during Appeal and to adopt a recommendation by the examiner 
in the last Office Action. 
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Summary of the Invention 

Appellant's invention provides a facility and user interface for searching one or more 
Common Object Request Broker Architecture ("CORBA") Interface Repositories for program 
objects based upon a set of user-specified search criteria. 

CORBA is a well-known architecture which allows programs and program components to 
discover the existence of each other, and to request and use the services of each other, during 
program run time, especially when the components are being physically executed on different 
computers interconnected with a communications network. 

Through CORBA, a program which is currently running may post a request for a specific 
type of service to a "broker". The Broker is a type of middleware which receives service 
requests, finds one or more interface definitions for available components which may perform 
the requested service, and provides the requesting program with those interface definitions. The 
requesting program can then remotely invoke a component to perform the service on its behalf 
using the component's interface definition. 

CORBA does not store all of the program components in a single repository. Rather, the 
CORBA broker facilitates the discovery of program components which are stored in physically 
distributed computers and storage devices. According to the CORBA definitions, CORBA 
stores only the interface definitions of each known component in an Interface Repository ("IR") 
using a specific interface description language known as Interface Definition Language ("IDL"). 

As such, a requesting program does not have to know where a needed component is 
stored, or even that it exists prior to needing its services. Additionally, the requesting program 
does not have to download or copy the component to execute it, but rather requests the service of 
the component using the component's interface definition which is retrieved from the Interface 
Repository ("IR") by the Broker. For example, a web site program which collects personal 
information from mortgage applicants may delegate the functionality of calculating interest and 
payment amounts to a function discovered and remotely invoked through CORBA. 

A problem arises during application program development which is intended to use 
CORBA to perform some or all of its functions through CORBA remote procedure calls. A 
designer may speculate that a particular function, such as a mortgage interest calculation 
function, will be available via a CORBA request when his or her program is executed some time 
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in the future. However, a designer cannot be certain that such a function will be available in the 
future, or even if the function is currently available. 

The present invention addresses this problem by providing a user interface and search 
facility which allows the designer to input certain component criteria, submit a request to a 
CORBA broker, and receive one or more interface definitions in return for components which are 
actually available to perform the requested service. This allows the designer to proceed with 
software design of his or her own program under the reasonable certainty that particular functions 
can be performed by other, distributed modules, at runtime sometime in the future. 

Issues 

Claims 1 - 39 were finally rejected under 35 U.S.C. § 102(b) as being anticipated by U.S. 
Patent 5,778,368, to Hogan, et al, issued July 7, 1998, a copy of which is attached hereto for the 
convenience of the Board. 

Examiner has stated that the Hogan patent properly anticipates each and every element 
and limitation of all presented claims, although the '368 patent does not explicitly recite using an 
Object Request Broker protocol, searching an Interface Repository, or displaying details of an 
Interface Definition. Examiner has stated, with certain rationale, that Hogan' s recital of 
Transmission Control Protocol/Internet Protocol ("TCP/IP"), and recital of a repository which 
stores program objects and certain descriptive information for each stored program object 
inherently teaches an Object Request Broker, an Interface Repository, and Interface Definitions. 

Examiner has agreed that "Hogan et al. showed program objects that were downloaded to 
a programmer's computer, rather than program objects that were called and executed on a 
computer remote from the programmer's computer" (see examiner's Summary of Interview, 
dated May 27, 2003). 

Grouping of Claims 

Claims 1 - 3, 7 - 12, 14 - 16, 20 - 25, 27 - 29 and 33 - 38 stand or fall together; claims 4, 
17 and 30 stand or fall together; claims 5, 18, and 31 stand or fall together; claims 6, 19, and 32 
stand or fall together; and claims 13, 26 and 39 stand or fall together. The reasons why these 
groups of claims are believed to be separately patentable are explained in the Arguments of this 
Appeal Brief. 
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The Examiner's Rationale 

Examiner's rationale for rejection of Claim 1 is that the '368 patent defines a system and 
method for searching "program repositories" such as internetworked databases which contain 
"program objects" or "repository units", which can be object oriented software. Examiner has 
stated that this is interpreted to mean that "[accordingly, the repositories themselves are object 
interface repositories, and are available on-line to various users". Further, examiner has stated 
"[t]he TCP/IP protocol utilized in Hogan, et al for conducting the search is considered to be an 
object request broker protocol by reason that this protocol allows the request of programming 
objects." Examiner also notes that the Hogan system and method provide a user with a display 
of available repository units along with attributes for the repository units. 

Examiner's rationale for rejection of Claim 2 is that Hogan's patent discloses the ability 
for the user to input a program object name for which to search as a "repository unit file name". 

Examiner's rationale for rejection of Claim 3 is that Hogan's patent discloses our ability 
for the user to input a repository name for which to search as a "repository name". 

Examiner's rationale for rejection of Claim 4 is that Hogan's patent discloses the ability 
of the user to specify searching for a specific object server identifier as a "processor type". 

Examiner's rationale for rejection of Claim 5 is that Hogan's patent discloses our ability 
for the user to specify an object container identifier as a "repository unit password". 

Examiner's rationale for rejection of Claim 6 is that "[s]ince the repositories contain 
object oriented programs.. .the queries for the repositories containing these objects would 
inherently be considered a standard CORBA interface repository query", thereby disclosing our 
ability to search using a CORBA IR query. 

Examiner's rationale for rejection of Claims 7 - 10 is that, by the same reasoning of the 
search criteria specified in claims 2 - 6, Hogan's system can display and sort the results on these 
criteria (e.g. object name, repository identifier, object server identifier, object container identifier, 
etc.). 

Examiner's rationale for rejection of Claim 11 is that Hogan's Figure 1 discloses a local 
disk "which is inherently capable of saving any input search or search result". 

Examiner's rationale for rejection of Claim 12 is that "[a]ny input of data or search query 
constitutes an input of a user remark and can be saved on the local disk". 
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Examiner's rationale for rejection of Claim 13 is that Hogan's "purchase record or 
purchased data ... reads as the claimed history list". 

With respect to rejection of claims 14 - 26, examiner states "see remarks" for claims 1 - 
13, respectively. 

With respect to rejection of claims 27 - 39, examiner states "see remarks" for claims 1 - 
13, respectively. 

Arguments 

We propose that errors cumulative to the improper final rejection under 35 U.S.C. 
§ 102(b) of independent claims 1, 14, and 27, as well as rejection of dependent claims 2 - 3, 7 - 
12, 15 - 16, 20 - 25, 28 - 29, and 33 - 38 are: 

(a) basing the rejections under 35 U.S.C. §102 over "inherent" functions not 
actually existing in the cited art; and 

(b) affording incorrect definitions to terminology found the prior art which are 
(1) not found in the cited art, (2) imported from our disclosure, and (3) in 
contradiction to established definitions, specifically by: 

(i) equating an OSI Level 7 protocol, the CORB A broker request 

protocol, to an OSI level 4 and level 3 protocol, TCP/IP; 

(ii) equating a "program object" with an "interface definition" of a 

program object; and 

(iii) equating a "repository of program objects" with a "repository of 

interface definitions". 
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In rejection of dependent claims 4, 17 and 30, we propose that errors cumulative to the 
improper final rejection under 35 U.S.C. § 102(b), in addition to the errors listed in (a) and (b) 
above, are: 

(c) affording incorrect definition to terminology found in the prior art which are 
(1) not found in the cited art, (2) imported from our disclosure, and (3) in 
contradiction to established definitions, specifically by equating an "embedded 
processor type" to a "program object server identifier" (e.g. a server name). 

In rejection of dependent claims 5, 18, and 31, we propose that errors cumulative to the 
improper final rejection under 35 U.S.C. § 102(b), in addition to the errors listed in (a) and (b) 
above, are: 

(d) affording incorrect definition to terminology found in the prior art which are 
(1) not found in the cited art, (2) imported from our disclosure, and (3) in 
contradiction to established definition, specifically by equating a "Repository 
Unit Password" as defined by the cited art to a "object container." 

In rejection of dependent claims 6, 19, and 32, we propose that errors cumulative to the 
improper final rejection under 35 U.S.C. § 102(b), in addition to the errors listed in (a) and (b) 
above, are: 

(e) affording incorrect definition to terminology found the prior art which are 
(1) not found in the cited art, (2) imported from our disclosure, and (3) in 
contradiction to established definition, specifically by equating a query 
for a "Repository Object" as defined by the cited art to a "Common Object 
Request Broker Architecture Interface Repository." 
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In rejection of dependent claims 13, 26, and 39, we propose that errors cumulative to the 
improper final rejection under 35 U.S.C. § 102(b), in addition to the errors listed in (a) and (b) 
above, are: 

(f) affording incorrect definition to terminology found the prior art which are 
(1) not found in the cited art, (2) imported from our disclosure, and (3) in 
contradiction to established definition, specifically by equating a "Purchase 
Record" as defined by the cited art to a "history list" of previously performed 
searches. 

Claims 1 - 3. 7 - 12. 14 - 16. 20 - 25. 27 - 29 

Examiner has not found art which specifically cites use of an Object Request Broker 
(ORB) protocol to search an Interface Repository (IR) which contains definitions of interfaces to 
program components. Instead, examiner has relied upon a number of "inherent" capabilities in 
order to equate TCP/IP to the CORBA ORB protocol, and to equate a repository containing 
program objects to a repository containing interface definitions. Examiner has agreed, however, 
that the Hogan system downloads program objects for local execution (or compilation) on a 
programmer's computer, while CORBA remotely invokes program objects which are executed 
on remote servers (see Examiner's Interview Summary dated May 27, 2003). 

TCP/IP compared to CORBA. Both TCP/IP and CORBA are well known in the art. 
Those ordinarily skilled in the art often refer to an Open Systems Interface, or "OSI", layer model 
for communications protocols which has 7 layers: 

(a) Layer 1 (the "lowest" layer) is the Physical Layer, which includes the type 

of physical medium used to convey the signal (e.g. electrical wires, optical media, 
wireless transmission, etc.); 

(b) Layer 2 is the Data Link layer, which provides synchronization for the 
physical level and does bit-stuffing for strings of 1's in excess of 5; 

(c) Layer 3 is the Network layer, which handles the routing of the data; 

(d) Layer 4 is Transport layer, which manages end-to-end control and error 
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correction (e.g. resending of packets that are not received in good condition); 

(e) Layer 5 as the Session layer, which sets up, coordinates, and terminates 
conversations, exchanges, and dialogs between the applications at each 
end of a connection; 

(f) Layer 6 is the Presentation or Syntax layer, often part of an operating system, 
which converts incoming and outgoing data from one presentation format to 
another such as a text stream to a window; 

(g) Layer 7 is the Application layer at which communication partners are identified, 
quality of service is identified, user authentication and privacy are considered, and 
any constraints on data syntax are identified. 

Examiner was presented for reference several third-party citations which follow this 
model in our reply dated May 23, 2003. This OSI stack is well known in the art, and presenting 
this information in the Appeal Brief is cumulative to the known art. 

The first strong indication that CORBA and TCP/IP are considerably dissimilar is that 
CORBA and TCP/IP do not belong at the same layer or level in the OSI model, thereby implying 
different functionalities and capabilities. 

TCP/IP consists of two pieces of protocol: Transmission Control Protocol (TCP) and 
Internet Protocol (IP). TCP runs at Layer 4 as a Transport protocol, breaking large amounts of 
data into packets, sequencing the packets, resending erred packets, etc. IP runs at Layer 3 as a 
Network protocol, performing routing and forwarding of data to their proper destinations 
according to addresses (e.g. IP addresses). 

By contrast, CORBA is a total architecture for enabling distributed program components 
to invoke each other, without having to copy the components from their original point of storage 
to be executed on a local processor. So, CORBA has a specific, high level protocol for 
programs needing to find other programs to contact a Broker service. That high level protocol 
runs at Layer 7 in the OSI model as an Application .. In fact, CORBA can be run on top of 
TCP/IP, with the requests for program objects being handled TCP/IP. CORBA can utilize the 
TCP/IP to transport and direct its requests to the CORBA Broker. CORBA, however, may also 
be run on top of other, non-TCP/IP protocols, as is well known in the art. 

We contend that TCP/IP is not capable of "requesting an object" by itself without a 
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higher level application program causing some action, and that the examiner's assertion that 
TCP/IP inherently can perform this function is unsupported by the cited art, and is not supported 
by the well-known literature concerning the two standards. 

To illuminate this problem in reasoning, one can ask that if TCP/IP were indeed able to 
"request program objects" on its own, why would a CORB A object broker request protocol be 
necessary in addition to TCP/IP to achieve distributed computing functions? 

To illustrate the error of rationale with another example, when a web browser requests a 
web object such as an image file or an HTML "page", TCP/IP does not perform such a request, it 
only conveys the request to the proper destination. It is well known in the art that Hyper Text 
Transfer Protocol (HTTP), which operates at the Application Layer #7, makes such a request. 
HTTP and CORBA, of course, are very different applications, which can use a common 
communication protocol (e.g. TCP/IP). 

In fact, Hogan follows this same OSI model, and states that HTTP or another A pplication 
layer protocol known as File Transfer Protocol ("FTP") is actually used to request and download 
program objects according to his invention: 

The Repository Server then downloads the results on to the Repository Clients and 
Repository Stations and, after further instructions from the user, downloads or checks-out, i.e., 
unpackages, the requested Repository Units - via FTP or HTTP mechanisms - to the user's 
desktop. (Hogan, Col. 8 line 65 through Col. 9 line 3, emphasis added) 

Certainly, it is well known in the art that CORBA, HTTP and FTP are very different 
applications, employed for very different functions and uses, although they are all application 
layer elements as opposed to lower-layer elements. 

Therefore, the examiner has erred in equating a layer 4 transport protocol (TCP) and layer 
3 network protocol (BP) with a layer 7 application protocol (the CORBA broker request protocol). 

Interface Repository c ompared to a Repository of Program Objects . To complete 
the rejection, examiner equated our step or limitation of searching an Interface Repository with 
searching a "respository of program objects." It is well known that CORBA enables use of 
distributed objects through mechanisms such as remote procedure calls (RPC). This means that 
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the program objects themselves are not co-located or stored in a common repository, but instead 
are stored on many different servers (e.g. distributed). 

In order to accomplish this, CORBA employs interface definitions to those program 
objects which are stored in a repository, thus creating an Interface Repository which contains no 
program objects, only interface definitions. CORBA uses a well-known Interface Description 
Language (IDL) to define these interfaces. 

Hogan's repository, by contrast, actually stores the program objects themselves, as 
evidenced by his disclosure: 

The Repository Clients 8 and 9 and Repository Station 11 access the appropriate 
Repositor y databases where the Repository Units meeting the requirements of a particular 
search reside. (Hogan, Col. 10, lines 62 - 65, emphasis added) 

In other words, Hogan's repository contains "Repository Units", which are defined by 
Hogan as: 

Repository Units: This is the smallest piece of information relating to embedded sofwtare 
stored in the MXP Repository. This component may be a Component, Framework, audio file, or a 
normal text or binary file or the real-time embedded software itself. (Hogan Col. 7, lines 28 - 34) 

... Repository Units which may comprise Software Source Files such as C, C++, Basic and Fortran, and 
Test software... (Hogan Col. 6, lines 38-31) 

Hogan's system requires a user to "check-out" a program object from his repository, to 
download it to his own local computer, and then to run it (or compile it) locally. By contrast, 
CORBA employs remote execution of program objects on their remote servers through the use of 
well-defined program interface definitions (e.g. no checking out, no downloading, no local 
execution required). This fundamental difference in operation of the Hogan system and object 
request broker systems was agreed to bv the Examiner fsee examiner's Interview Summary. 
05/27/2003). 

Note that there is absolutely no indication that Hogan's "repository unit" may be an 
Interface Definition, especially as defined by the well-known CORBA Interface Definition 
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Language (IDL) specification. Therefore, the examiner has erroneously equated Hogan's 
"Repository Unit" to an Interface Definition, and has erroneously equated Hogan's "Repository 
of Repository Units" to an "Interface Respository", especially in the context of a novelty 
rejection. 

Claims 4. 17. and 30 

Claim 4 is dependent on Claim 1, Claim 17 is dependent on Claim 13, and Claim 30 is 
dependent on Claim 27, and thus they are not properly anticipated by the Hogan patent for the 
reasons discussed supra. 

Further, in examiner's rationale for rejection of Claims 4, 17 and 30, examiner has 
erroneously equated Hogan's "processor type" attribute to our "program object server identifier". 

By "program object server identifier", we mean the name or address of the server 
computer which will remotely execute a selected program object on behalf of a requesting 
program. It is unimportant to the requesting program what kind or type of processor (e.g. Intel 
Pentium, Motorola PowerPC, etc.) that server employs, as the objective is to simply get the 
results of the service from the invoked program. This definition is consistent with the concepts 
of CORBA and distributed computing. 

Hogan's disclosure relates to a development tool for designing real-time embedded 
software (see Hogan's abstract). In fact, Hogan's disclosure specifically mentions several well- 
known embedded software operating systems such as VxWorks, PSOS, and SPOX (col. 5, lines 
65 - col. 6 line 1). The only reasonable interpretation of Hogan's "processor type" attribute is 
what brand, model or family of processor (e.g. Motorola 56000, Intel x86, IBM PowerPC, etc.) 
on which the software is designed to run, as is consistent with terminology and concepts of real- 
time, embedded firmware and software development. 

Hogan's disclosure is completely silent as to an attribute regarding a remote server name, 
address, or other identifier for the program object. To equate Hogan's "processor type" attribute 
to a remote server name unfairly imports our definition into his disclosure, as well as 
unreasonably redefines his term outside the scope of his invention (e.g. from embedded software 
development to distributed computing arrangements). The examiner has cited no art which 
establishes "processor type" as being a server name, server address, or other type of server 
identifier. 
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Therefore, the examiner has erred in equating an embedded processor type to a server 
identifier, especially in a novelty rejection context. 

Claims 5. 18, and 31 

Claim 5 is dependent on Claim 1, Claim 18 is dependent on Claim 13, and Claim 31 is 
dependent on Claim 27, and thus they are not properly anticipated by the Hogan patent for the 
reasons discussed supra. 

Claims 5, 18 and 31 specify that our search facility allows a user to search for a specific 
"object container identifier" criteria, such as a container name. The terms "container" and 
"object container" are well known in the object oriented programming art as a construct which 
includes or holds an object, itself having a container name or identifier. 

Examiner has erroneously equated Hogan' s "Repository Unit Password" to our "object 
container" in rejection of Claims 5, 18, and 31. Hogan provides no further definition to his 
"password" term, and the examiner has not cited any other passages to establish a non- 
conventional definition of the term. 

It is only reasonable to assume that a "password" is a conventional password (e.g. a 
special value, string, or number which allows access to something). This, obviously, is not the 
same as a container name as is well understood by those in the object oriented programming art. 

Thus, the examiner has erred in equating a "password" to an object container name, 
especially in a novelty rejection context. 

Claims 6. 19, and 32 

Claim 6 is dependent on Claim 1, Claim 19 is dependent on Claim 13, and Claim 32 is 
dependent on Claim 27, and thus they are not properly anticipated by the Hogan patent for the 
reasons discussed supra. 

Claims 6, 19 and 32 specify use of a CORBA Interface Repository, as there are other 
object request broker architectures (some standardized, some proprietary) known in the art to 
which our invention may be applied in alternate embodiments. Our preferred embodiment 
employs a standardized CORBA protocol, so claims 6, 19, and 32 specify these elements and 
steps. 

In the rejection of Claims 6, 19, and 32, the examiner has stated "Since the [Hogan] 
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repositories contain object oriented programs (col. 8, lines 55 - 58), the queries for the 
repositories containing these objects would inherently be considered a standard CORB A 
interface repository query." 

Examiner has not provided any evidence or citations as to this "inherent" fact, and the 
Hogan disclosure is silent as to his Repository Units possibly being "Interface Definitions", 
especially interface definitions using the well known standard CORB A Interface Description 
Language. 

Certainly, there are other, non-CORBA interface description methodologies, and certainly 
object oriented programming does not necessarily require the implementation of CORBA IDL. 

Therefore, we propose that the rejections of these claims are erroneously based on non- 
existing inherency of CORBA IDL with respect to object oriented programs in general, especially 
in a novelty rejection context. 

Claims 13. 26. and 39 

Claim 13 is dependent on Claim 1, Claim 26 is dependent on Claim 13, and Claim 39 is 
dependent on Claim 27, and thus they are not properly anticipated by the Hogan patent for the 
reasons discussed supra. 

Claims 13, 26, and 39 specify recording of a "history list" of criterion on which previous 
searches have been performed. Examiner has equated our search criterion history list to Hogan 1 s 
"purchase record of purchased data". In fact, Hogan does not disclose our search criterion 
history list, but only a record of purchases made: 

Once the Repository Unit is checked-out . the repository tools create a purchase record 
for the appropriate billing account, and updates the re-use count in the Repository database as well 
as the appropriate information concerning the re-user. (Col. 15, lines 14 - 17, emphasis added) 

As this is fairly interpreted, Hogan' s "purchase record" is only created subsequent to the 
"checking out" of a program module. However, the Hogan patent is silent is to creating a record 
of program modules which are found in searches but which are not subsequently checked out or 
purchased. Indeed, it would be unfair to charge a user for simply searching for and finding an 
available program component which meets his or her specified criteria, as each search does not 
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necessarily result in a sale on every occasion. 

Our claims specify storing "previously stored [search] criterion input and lists", which is 
fundamentally different from recording details of a subsequent purchase. Our invention creates 
a history list to record the criteria upon which previous searches have been made, without 
concern for whether or not a program is checked out or purchased. Therefore, examiner has 
erred in equating our "history list" to a "purchase record", especially in a novelty rejection 
context. 

Summary 

For the foregoing reasons, it is submitted that the examiner's rejections of Claims 1 - 39 
were erroneous, and reversal of his decisions is respectfully requested. 
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Claim 1 (amended): 

A method for allowing a user to search program object interface repositories, said 
Interface Repository (IR) comprising an on-line database accessible through Object 
Request Broker(ORB) protocol , said interface repositories being stored on one or more 
server computers and containing metadata or definitions of said available program 
component interfaces, the method comprising the steps of: 

providing a plurality of search criteria fields and a search icon on a graphical user 
display of a networked client computer; 

receiving one or more criterion input from a user via said search criteria fields 
followed by selection of the search icon; 

performing at least one search of at least one IR using said ORB protocol for 
interfaces to available program objects for which a match exists between the program 
objects' specifications and the criterion input; and 

displaying a list of available interfaces to program objects which match said 
criterion input on said graphical user display. 

Claim 2 (original): 

The method as set forth in Claim 1 wherein said step of receiving one or more criterion 
input from a user includes receiving a program object name. 

Claim 3 (original): 

The method as set forth in Claim 1 wherein said step of receiving one or more criterion 
input from a user includes receiving program object repository identifier. 

Claim 4 (original): 

The method as set forth in Claim 1 wherein said step of receiving one or more criterion 
input from a user includes receiving program object server identifier. 
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Claim 5 (original): 

The method as set forth in Claim 1 wherein said step of receiving one or more criterion 
input from a user includes receiving program object container identifier. 

Claim 6 (amended): 

The method as set forth in Claim 1 wherein said step of performing at least one search of 
at least one interface repository includes performing a Common Object Request Broker 
Architecture (CORB A) Interface Repository query. 

Claim 7 (amended): 

The method as set forth in Claim 1 wherein said step of displaying a list of available 
interfaces to program objects includes sorting the list by program object name. 

Claim 8 (amended): 

The method as set forth in Claim 1 wherein said step of displaying a list of available 
interfaces to program objects includes sorting the list by program object server identifier. 

Claim 9 (amended): 

The method as set forth in Claim 1 wherein said step of displaying a list of interfaces to 
available program objects includes sorting the list by program object container identifier. 

Claim 10 (amended): 

The method as set forth in Claim 1 wherein said step of displaying a list of interfaces to 
available program objects includes sorting the list by program object modification date. 
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Claim 11 (original): 

The method as set forth in Claim 1 further comprising the step of storing said criterion 
input and said list of available program objects for later recall or review. 

Claim 12 (original): 

The method as set forth in Claim 1 1 wherein said step of storing said criterion input and 
list further comprises storing a user-supplied remark associated with the criterion input 
and list. 

Claim 13 (original): 

The method as set forth in Claim 1 1 further comprising the step of providing a history list 
viewable by a user, said history list comprising a summary of previously stored criterion 
input and lists. 

Claim 14 (amended): 

A computer-readable medium containing program code suitable execution by an 
object-oriented software development workstation, said program code allowing a user to 
search program object Interface Repositories (IR), said interface repositories comprising 
an on-line database accessible through a Object Request Broker (ORB) protocol, said 
interface repositories being stored on one or more server computers, said available 
program objects' interface descriptions containing metadata or definitions of said 
available program component interfaces, said workstation having a processor suitable for 
executing program code, the program code causing the workstation to perform the steps 
of: 

providing a plurality of search criteria fields and a search icon on a graphical user 
display of said workstation; 

receiving one or more criterion input from a user via said search criteria fields 
followed by selection of the search icon; 

performing at least one search of at least one IR using said ORB protocol for 
interfaces to available program objects for which matches exists between the program 
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objects' specifications and the criterion input; and 

displaying a list of interfaces to available program objects which match said 
criterion input on said graphical user display. 

Claim 15 (original): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
receiving one or more criterion input from a user includes program code for receiving a 
program object name. 

Claim 16 (original): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
receiving one or more criterion input from a user includes program code for receiving 
program object repository identifier. 



Claim 17 (original): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
receiving one or more criterion input from a user includes program code for receiving 
program object server identifier. 



Claim 18 (original): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
receiving one or more criterion input from a user includes program code for receiving 
program object container identifier. 

Claim 19 (amended): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
performing at least one search of at least one interface repository includes program code 
for performing a Common Object Request Broker Architecture (CORB A) Interface 
Repository query. 
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Claim 20 (amended): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
displaying a list of interfaces to available program objects includes program code for 
sorting the list by program object name. 

Claim 21 (amended): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
displaying a list of interfaces to available program objects includes program code for 
sorting the list by program object server identifier. 

Claim 22 (amended): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
displaying a list of interfaces to available program objects includes program code for 
sorting the list by program object container identifier. 

Claim 23 (amended): 

The computer-readable medium as set forth in Claim 14 wherein said program code for 
displaying a list of interfaces to available program objects includes program code for 
sorting the list by program object modification date. 

Claim 24 (amended): 

The computer-readable medium as set forth in Claim 14 further comprising program code 
for storing said criterion input and said list of interfaces to available program objects for 
later recall or review. 

Claim 25 (original): 

The computer-readable medium as set forth in Claim 24 wherein said program code for 
storing said criterion input and list further comprises program code for storing a 
user-supplied remark associated with the criterion input and list. 
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Claim 26 (original): 

The computer-readable medium as set forth in Claim 24 further comprising program code 
for providing a history list viewable by a user, said history list comprising a summary of 
previously stored criterion input and lists. 

Claim 27 (amended): 

An interface repository search facility in an object-oriented software development 
workstation for allowing a user to search program object Interface Repositories (IR), said 
interface repositories comprising at least one on-line database accessible through a Object 
Request Broker protocol, said interface repositories being stored on one or more server 
computers, said available program objects' interface descriptions containing metadata or 
definitions of said available program component interfaces, said interface repository 
search facility comprising: 

a graphical user interface having a plurality of search criteria fields and a search 
icon displayed thereon; 

one or more user input devices for inputting one or more search criterion into said 
search criteria fields, and for selection by a user of the search icon; 

an IR searcher for searching one or more ORB interface repositories using said 
ORB protocol for interfaces to available program objects for which matches exists 
between the program object specifications and the input search criterion; and 

a result list of interfaces to available program objects which match said search 
criterion, said result list displayed on said graphical user interface. 

Claim 28 (original): 

The interface repository search facility as set forth in Claim 27 wherein said search 
criteria fields includes a field for specifying a program object name. 

Claim 29 (original): 

The interface repository search facility as set forth in Claim 27 wherein said search 
criteria fields includes a field for specifying a program object repository identifier. 
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Claim 30 (original): 

The interface repository search facility as set forth in Claim 27 wherein said search 
criteria fields includes a field for specifying a program object server identifier. 

Claim 31 (original): 

The interface repository search facility as set forth in Claim 27 wherein said search 
criteria fields includes a field for specifying a program object container identifier. 

Claim 32 (amended): 

The interface repository search facility as set forth in Claim 27 wherein said interface 
repository searcher is adapted to perform Common Object Request Broker Architecture 
(CORBA) Interface Repository queries and searches. 

Claim 33 (original): 

The interface repository search facility as set forth in Claim 27 further comprising a result 
list sorter for sorting the result list by program object name. 

Claim 34 (original): 

The interface repository search facility as set forth in Claim 27 further comprising a result 
list sorter for sorting the result list by program object server identifier. 

Claim 35 (original): 

The interface repository search facility as set forth in Claim 27 further comprising a result 
list sorter for sorting the result list by program object container identifier. 

Claim 36 (original): 

The interface repository search facility as set forth in Claim 27 further comprising a result 
list sorter for sorting the result list by program object modification date. 
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Claim 37 (original): 

The interface repository search facility as set forth in Claim 27 further comprising a 
search storing facility for storing said criterion input and said list of available program 
objects for later recall or review. 

Claim 38 (original): 

The interface repository search facility as set forth in Claim 37 wherein said search 
storing facility further comprises a remark editor for storing a user-supplied remark 
associated with the criterion input and list. 

Claim 39 (original): 

The interface repository search facility as set forth in Claim 37 further comprising a 
history list manager for creating and producing a search history list viewable by a user, 
said history list comprising a summary of previously stored criterion input and lists. 



United States Patent m 

Hogan et al. 



US005778368A 
[U] Patent Number: 
[45] Date of Patent: 



5,778,368 
Jul. 7, 1998 



(54) REAL-TIME EMBEDDED SOFTWARE 
RESPOSITORY WITH ATTRIBUTE 
SEARCHING APPARATUS AND METHOD 

[75] Inventors: Keith Hogan. Olney; Thomas H. 

Scnoll; William E. Wltowsky, both of 
Gaithersburg, all of Md. 

[73] Assignee: Telogy Networks, Inc.. Germantown 
Md. 

[21] Appi. No.: 642 ? W0 
[22] Filed: May 3, 1996 

W ^LCL 6 G06F 15/76 

[52] US. CI 707/10; 707/1; 707/9: 

707/10; 395/187.01; 395/200.33; 395/200.47; 

395/200.55 

[58] Field of Search 707/9. 10.4. 104- 

395/200.33. 200.47. 200.551 187.01 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,805.134 2/1989 Calo et al _ 364/900 

5,022.028 6/1991 Edmonds et al 371/25 1 

5.257,369 10/1993 Skeeo et al „ .'. 395,650 

5J13.614 5/1994 Gocadmana et al. .. 395/500 

5J77259 12/1994 Butler el al „ 379/93 

5.421.0O9 5/1995 Piatt " 395/600 

5.446.842 8/1995 Schaeffcr e* al 395/20001 

5.457J05 10/1995 Aid et al 23*379 

5.483,652 1/1996 SudamaetaJ \ 395,600 

5.546.455 8/1996 Joyce et al. „.„ „., 3707265 



5,553082 9/1996 Parish et al. 

5,596,632 1/1997 Curtis et al. 

5.640.446 6V1997 Everett ei al „ 

5,659,735 8/1997 Parrisbetal. 



« 707/10 
. 379/189 
379/115 
.. 707/10 



Primary Examiner-Thomas G. Black 
Assistant Examiner— Jean R. Homere 
Attorney, Agent, or Firm—Robots & Browneli. LLC 



[57] 



ABSTRACT 



The Real-Time Embedded Software Repository Apparatus 
fully characterizes, evaluates, and reuses real-time embed- 
ded software that is placed or stored in a repository database. 
The Repository System comprises at least one Repository 
Client and at least one Repository Server and utilizes 
simulation and translations techniques to allow Real Time 
Embedded Software (KTES) to be re-used, played, and 
evaluated on various desktop development environments or 
target operating environments. The Repository System orga- 
nizes and processes Repository files as Repository Units 
which may comprise Software Source Files and Test Soft- 
ware. Repository Units also contain Attachments that pro- 
vide current and historic information to static files that are 
stored in the Repository. The Repository Units axe further 
characterized using analysis tools (software analysis) which 
allow the user to associate fixed and user defined Attributes 
to the RTES. A real-time embedded component 
(Component) provides a clear and well defined software 
interface to function at a high level of interaction with the 
KTES- Templates for both searching and displaying infor- 
mation in a multimedia format are also provided. 

42 Claims, 12 Drawing Sheets 
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REAMTME EMBEDDED SOFTWARE shorten development time scales 

REPOSITORY WITH ATTRIBUTE incn^M conjoin, 

SEARCHING APPARATUS AND METHOD complex,ty 

increase quality 

FIELD OF THE INVENTION 5 decrease power utilization 

The present invention relates generally to a Multi-Cross increase performance 

Platform Repository System for real-time embedded decrease cost 

software, and more particularly, the present invention pro- provide highly integrated solutions 

vides the means to fully characterize, evaluate, and reuse These factors are forcing developers to increase utiliza- 

real-tirae embedded software that is placed or stored in a "> tion of existing in-housc software, pursue joint development 

repository database. activities with outside organizations that specialize in related 

BACKGROUND AND DESCRIPTION OF THE SJ^h-' ^ J™? $0ftWC ^ tlo P m ^ m ^od- 

RELATED ART r * , - J 

A current trend in software development methodologies is 

Real-time embedded software (RTES) is software that 15 t0 aUow a higher level of integration amongst corporate 

executes on customer hardware boards that are found within software portfolios. As such, joint development of software 

end-user products such as cellular phones, ATM switches, * fld software modules between companies is becoming more 

and anti-lock brake systems. This software typically opcr- prevalent, and in many instances, is required for a corapa- 

ates custom displays, user interfaces, communication nv ' $ products to retain their technical edge-^especiaUy 

interfaces, and motors. By nature. RTES is not visible to the 20 w **en *n average product lifespan is a mere 18 to 24 months 

end user because it is completely contained within the The lack of visibility of RTES. however, makes such joint 

product. Such software is also generally not visible to the developments quite impractical Software Engineers have 

company that developed it This lack of visibility results in difficulty displaying software capabilities other than those 

part from the fact that it operates through external interfaces vis iWe via the external interfaces of an existing product For 

and in part from the absence of products that permit and 25 example, routines that implement algorithms cannot be 

enhance both the visibility and reusability of KTES. demonstrated or displayed to a technology partner by only 

Lack of RTES visibility leads to wastes in staff utilization showing the external interfaces of the product, 

as well as decreased software quality because: Rc * usc of software of varying types has been the subject 

NIH (Not invented here) Syndrome is reinforced when an ° f SCVCTai "*yentions. To ^ end classical repository tech- 
engineer cannot demonstrate that an existing piece of 30 Doiogy P rovidcs a means for storing and recalling items 

software works and conforms to certain quality stan- fr ° m a ftlobal $tor age media such as a database. This 

dards technology, however, does not fully respond to the need of 

Engineers routinely in part 're-invent the wheel" on small f USCr *\ fuUy charactcrizc or fully evaluate RTES that may 

and medium size software modules because software ? * » f.*? 1 ?"* This tec *">ology also does not 

that they design and code is bound to the project 25?^ pr0Vlde ^ ormalio0 aboul ^ to departments 

software and cannot be easily reused WI . thm a compaDy < e * accounting departments) to deter- 

Software components from third party vendors or devel- rT^^S £ SEES *«T 1^ UA ^ 

opmeot partners cannot be easilVreused because rw 5.JWZ.028 to Edmonds et al. discloses a system for 

abiiity and quality of software that thev del? ver . a ? \ f?** vcnficaUo ° su <* »* » system 

Uck of visibility ofKTESalso amatively Unlets the £ ^ ^ ^ W fadJitatCS ***** 

management assets of a developnTccganSf For tuTS ^ ?*1 the quality 

example, because of lack of visibSty- organization, ror ^uo of software development. This system does not pro- 

FWrt« ^ nnnt i u ^ , J u , wde visibiUty at the desktop into the operability of RTES to 

Projects cannot be scheduled based on software re-use 45 any user other than the software developer a7 me time of 

Management doesn't know exactly what software exists testing and further does not address issua of concern to 

m -house management as outlined above. 
In-house software assets that are known and located us - Pat No. 5.446.842 to Schaeffer et al discloses an 
cannot easily be evaluated for re-use object-oriented collaboration system using framework archi- 
Management cannot easily access lower cost labor pools 30 tccture to provide current access to a framework application 
in places like universities and foreign countries. b y users. The users can collaborate over the appU- 
Management cannot directly move engineers and pro- CatioD and j Qintl y produce a finished product using standard 
grammers between groups because of the difference in d^sfopmeni frameworks. The applications commence in a 
tools, methodologies, and quality standards. consistent state and are maintained by distributing corn- 
Lack of visibility also negatively impacts the business 55 nUndl t0 Mch a PP Uc4ti on ** *ey are entered at a controlling 
aspects of the corporation that develops RTES* system. This system does not provide for storing 
Executives cannot identify corporate software assets ^ff^. 8 °. d d ^ O0StratiD 8 KTES from a set of dis- 
except at a finished product level. ^ repositories. This system further does not permit 
Tools do not exist to help in detennining the value of „ ^1 ^er than to the users during software 
corporate software assets. r?c iT. vr , ^. _ 

select each remote computer system for software installation 
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or to provide a file containing a list of ail remote computers times as needed. This design would also enable the software 

on the system. In this system the software is installed on the engineer to develop a software application from start to 

target computer, but it does not address real-time software finish without the dependency on target hardware and based 

development or the re-use of software. on the maximum re-use of existing software assets 

U.S. Pau No. 4.805.134 to Calo et al. discloses an 5 cttvtw 

electronic system for accessing graphical and textual infor- SUMMARY OF THE INVENTION 

mation. This invention teaches an extended architecture to It is therefore an object of the present invention to provide 

foster cooperation among a wide range of remotely located * Repository System to allow re-use of real-time embedded 

terminals and databases. This system is based on database software. 

technology and does not teach the re-use of PTES. This jo It is a further object of the present invention to provide an 

invention is further intended to support textual and graphical entire architecture for a Repository System comprising 

information: however, it does not address specific require- distributed Repository Servers communicating with multiple 

raents of RTES — or support to the development process. Repository Clients simultaneously. 

The development and execution of RTES on the desktop It is yet a further object of the present invention to provide 

is incomplete unless it has the capability of simulating 15 a Repository Server that includes desktop computer based 

multiple processor target platform (i.e. the platform on servers, security packages, search and display templates, 

which developed RTES is to run)configuraUons. The devei- FTP server software. Repository Server storage medium, 

opment environment is also incomplete unless it provides and software analysis tools for analysis of real-time soft- 

the ability for software engineers to test the software that ware. 

would operate in such an environment from their own 20 n is still yet another object of the present invention to 

desktops. As such, a simulation technique is needed when facilitate software characterization through the use of soft- 

the deve opment software engineers are analyzing or down- ware attributes, wherein said attributes provide a description 

loading (from other systems) RTES. An example of such a 0 f real-time embedded software for future review 

technique is represented by U.S. Pat No. 5 J 13.614 to characterization, and demonstration of the real-time cmbed- 

Goeaclman et al. which discloses software for direct coo- 25 ded software on the user's desktop 

vcrs.on of programs between different hardware architecture It is still a further object of the present invention to 

computer systems. Tlus is accomplished via "translation a Rcpository ^ conpnJ^cb 

Z^Zl r ,v " ***** M Ti C If*. S °T warc «* c5em Helper AppuSTand accorr^nybg 

£T£/ "! au h s . casc * 0D whldl , ^ is to be applications to accesTrcauLe embedded sofW on ! 

developed which is analogous to the "target platform" noted 30 diluted Repository System, 

above )on the computer on which software for the target lt ie tfin ' . , , . 

platform is to be developed. This virtual hardware environ- * 1 ?HjS.!^?? °' * C J^ 00 . 10 

ment is provided in thedevelopment computer to manage a Reposuory Client coropnsing simulated Operating 

different* the address sprouts in the devl Z^Z^Z^ "* " ^ ~ " 

opment and target computers. The "translator software". 35 ■ , * " 

similar to emulation software in many respects, takes as its " a fxmhci objcct of P rcscDl invention to 

input, programs compiled from the source machine and J s ^ nd -* Jooe Repository Station for real-time 

decodes and maps each source machine instruction to one or " nbcddcd so ^ arc comprising Repository web server and 

more of the target machine instructions, which thereafter. ca P ablLacs - Md dynamic web pages, 

replicates the functionality of each source machine instruc- 40 U 15 aDOthcr <* * e present invention to provide a 

tion. The mapping and decoding is performed off line and stand-alone Repository Station for real-time embedded soft, 

the resulting software translation is saved. The translation warc com P risin 8 Repository Unit Attributes, a Repository 

can be executed as many times as the user wishes, rather Scarch cn P nc ' real-time software analysis tools, a Reposi- 

tnan being recreated each time the application is to be tory CD ' and acccss software to allow software to be 

executed on the target machine. 45 ^fcteriied. search by characteristics, and retrieval for 

In view of the re-use problem noted, in conjunction with P° ssiWc re-use. 

the existing art. a system for overcoming the shortcomings ^ is a^o^er object of the present invention to provide 

of existing software development strategies would include a a Rc P ositorv System comprising at least one user search 

repository system for the storage, retrieval, and re-use of template and at least one user display template which utilize 

RTES. Such a system would operate simultaneously on a so Attributcs 10 characterize and formal Repository Units, 

variety of platforms and allow RTES development organi- thereby allowing the user to perform customized searches of 

zations to fully characterize their software modules, soft- repository software components and allow the user to dis- 

ware sub-systems, and software systems in a way that P lav results in a custom format, 

facilitates software visibility and re-use. This would be 11 * s $tiu mother object of the present invention to provide 

accomplished by providing a system that allows an engineer 35 1 Repository Unit structure for real-time embedded software 

to search database repositories that contain RTES compo- objects comprising Repository Attributes and Attribute 

nents scattered throughout a community of multiple reposi- v &iues. Unit Descriptor Files, and a Unit Source Package all 

tones. This system would also use a variety of access of whi ch facilitate software re-use. 

methods to access the repository database^) and allow the It is also another object of the present invention to provide 

software engineer to download the requested RTES compo- 60 fl dynamic Repository display that is self configuring based 

nents onto his desktop. Once the RTES components are on the response from the Repository search, 

downloaded, the software engineer would be able to It is yet an additional object of the present invention to 

assemble the appropriate components, edit them according provide a Repository Station and Repository Client for 

to his specific software application design, and run the new checlring-in or checking-out Repository Units from the 

combination as if it were on the target computer. The 65 Repository database. 

software engineer would then be capable of reusing the It is an additional object of the present invention to 

components modules received from the repository as many provide a Repository Station and Repository Client Helper 
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u- --.1 / uouumk. engineer to fully characterize a real-time embedded software 

'? Uo £ ^ °J the P**" "vention to module. software sub-system or software system in a 

provide i Repository Client and Repository Station Helper ner that facilitates its re-use as well as achieves vuibiUtvof 

Application that downhuds and plays real-time embedded 5 the software module. The software ■S^^SSeM? 

Ell", 0V ° " Ulterne,workc<1 such as the system or software system on provide added value to an 



entire organization. 



It * also an additional object of the present invention to The present invention provides platform indeoendent 

provde Repository Units that contain additional analysis access to the content, of 

information, such as real-tin* Operating System Call RcLn '« permitting the user to otiSe a iSSSSV^K t a 

"^l".^ Pr atin8 Sy " em ^ UUUziUon - UNK >' ^™P^ or a rnair^maciLe to .c£s! 
it is an added object of the present invention to provide a reusable software components within the Repository data- 
Repository web page based administrative interface for bases. ' 

SS^utr^ gaCReM,0rySerVeraDd .5 th ^^-cn«io.aUo«4ieve,highva,ueadded,o 

».«.-»« added objec, of the present invention to l^SCSiKK,; 

ETIS " RepOS,t0ly ^^tive interface for eonngur- varying levds of rxograrnmingtSlls^ »d IXelTkl 

mgand adromstenng the Repository Server and Repository Repository SytxtZZ^^VuiTZt^oM 

Tt . ' . L . , 2o Wlth Attributes that are applicable and meaningful to other 

u is also ao added object of the present invention to organizations within a company, for example information 

provide an administrative package that updates browse and such as cost, value. andleUid tecSj Z 

Z'tZ^™ " WCU "P 4 "* 0 ' 0 " * nd access lists, creates attributes that technically relate to the KTESiLdS (i.e lines 

^\»^}<^rt'^'y^1tou* u . of code. etc.). To this end. the present £en£n incluSe 

corr^leuag the check-in process for new Repository Units. capabilities that are applicable to an entire range of users 

as well as checking security logs and resolving security from marketing, to business development, to accounting 

1SSUCS - among others. 

These and other objects and advantages of the present The Repository System organizes and processes Reoosi- 

Zn t**™ ^ed in the art toxy files as Rectory Units im^n^S^W 
^^TT R '° t J hK ***** dCSCripti ° n 0f * e 30 Source Flies such asC C++. Basic, and ror^«d^ 

Ae ^R . V p 8 ^*c Md * C aPPCDdCd CUdmS ' S ° ftWVC such « ^ generation device 

ram. an. M;!^ Embedded Software Repository Appa- simulation code. Repository Units also contain Attachments 

hum ; and Method ( the present invention") is designed to that provide current and historic information to static files 

7," USC a ° d ofKreS -™ J capability is that are stored in the Repository. These Attachments may be 
Provided by aUowmg a rrmlutude different files or groups 35 voice files containing audio descriptions of the software 

or rues to be stored and utilized in describing. graphic data or any other data type that would help describe* 

dernonstraong or providing support for the re-use of RTES the RTES in question. The Repository Units are further 

ZZ^1\ ? * lth Such texriviivt files. These files characterized using analysis tools (software analysis) which 

^U!;^^' *5^ c " audio - voicc <* other file types allow the user to associate fixed and user defined Attributes 

ut to ^ to the RTES. The Rcpo$itCfV Vails m activc cntiUe ™ 

* ? Ca * a ^mcdia presentation of the RTES allow the addition of more attributes. E-mail threads prob- 

to^ation! Md UClL,dC UVC " ltcractivc ,cm re P° rtin « thre * ds - counts, and lest suites.' 

Th^ p~J?!!ts«, c - , v A^t^^bc^dedconponentiCorrirxmenn 

pos^leas t one Repository Client and at least one Reposi- 43 - component in the software allows the Repository System 

f?°«tory Client with a means to fully high level capabilities include playable RTES on the desktop 

characterize, retrieve, evaluate, and demonstrate, via fixed as as well as quality and code analysis 

distributed LANs across the Internet, on distributed Wide ^posuory. 

Area Networks (WAN), on distributed Metropolitan Area BRIEF DESCRIPTION OF THE DRAWINGS 

Networks (MAN), or any combination of the above— and « yiG 1 R«i Tin,, p™k~m^ c « 

may be any of a wide variety of desktop (PC UNIX MAH , * J. KcaJ ' Timc Embedded Software Repository Sys- 

rnixueomputer. or mainframe platfoZ. °' tcn > Architecture Overview. 

The present invention also utilizes the simulation and D^i^^^^,* RcaJ " W Embedded Software 

translationai techniques similar in function to mat^cTh TnV * * Arch,tccture ' 

disclosed in Goettelmann et al. (as described above) and 60 . , ^- Taac Embedded Software Repository Sys- 

othcr known methods, to allow RTES to be re-used and to Interaction Row. 

be played and evaluated on various desktop development FIG ' 3 Rc P°sitory System Login Screen, 

environments or targe* operating environments, thereby flG - * Repository System Search Template 

r^ W WC T °^ au : oQaJ ^ the TO 5 Repository System Search Template with a Partial 

real-time appucauons. The system of the present invention 65 Complete Attribute List. 
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FIG. 8 Search Rcqucsl Interaction. to run on a multitude of Operating Environments. This 

FIG. 9 Helper Application. software unit, typically a Repository Unit is in a serai- 

FIG. 10 System Use Overview complete state requiring the addition of Components to 

FIG. 11 Binary Tree Utility a ^^P^ application. The Frameworks can be 

s loaded to the desktop, and then the Components can be 

DETAILED DESCRIPTION OF THE addc ? t0 thc Frameworks, at which time the completed 

INVENTION Application can be executed on the Desktop. 

Repository System: This is a system that comprises the 

For purposes of the description and claims relative to the Repository Client. Repository Server. Repository Station, 

system of the present invention, the following terms shall to and Repository database. 

have the meanings set forth below. Repository Server: This is a computer with programs 

Definitions based on web server technology which contains a Reposi- 

The following definitions are applied throughout this toy file system that allows storing, searching, and retrieving 

application. of Repository Units. 

CGI: Common Gateway Interface. This is the interface 15 Repository Client: This is a computer with programs 

that is provided by web servers that connect to custom based on web browser technology utilizing custom Reposi- 

appiications programs. tory programs which allows access to the Repository Serv- 

FIP: Fde Transfer Protocol. This is an application which en. 

is used to transfer files using the TCP/IP protocol. Repository Station: This is a Repository System compo- 

HTTP: Hyper-Text Transfer Protocol This is a protocol 20 Dent that provides both client and partial server function ah' ty 

used by web servers to transfer web documents to clients. The Repository Station provides client functionality when 

HTML: Hypertext Markup Language, This is a standard accessing a Repository Server, and provides partial server 

language that the web browser interprets to create multime- functionality when functioning as a stand alone system 

dia displays with entries that link to other documents. accessing a local Repository CD or disk. 

RTES: Real-time embedded software. This is software 25 Repository System Overview 

that is intended to be executed on an embedded processor Referring to FIG. 1 a Repository System overview is 

syaera ' shown. The complete Repository System provides the user 

Repository Unit: This is the smallest piece of information 2 with the capability of re-using real-time embedded soft- 
relating to embedded software stored in the MXP Reposi- ware (KTES)from a set of distributed Repositories 3. 4. 5 
tory. This component may be a Component, Framework, w and 6. The user gains access to the Repositories via a 
audio file, or a normal text or binary file or the real-time networked system which includes PCs. MAC's. UNIX 
embedded software itself. A Repository Unit can also rep- workstations. Windows NT. or other similar systems known 
rose nt a collection of files with any combination of the above in the field. These systems are known as Repository Clients 
stated file types. or Repository Stations (if the Repository Client also cora- 

Atmbute: This is a user assigned or system defined 35 prises local CD Repositories). The accessed Repositories 
characteristic that is used to describe a Repository Unit An comprise in-house server or local disk Repositories 3. 
Attribute can have a name, or include a value and a data Repository technology-specific CD Repositories 4. third 
type. A data type can include a name, format, value. party Repositories 5 accessed via the Internet or other 
validation, security access parameter, and other similar internetworked systems, or other internal off -site corporate 
t yP es - 40 Repositories 6 accessed via the Internet or other internet- 
Packager: This is Helper Application system that bundles worked system. Stand-alone Repository Systems are also 
Repository Units. The Packager runs on the Repository envisioned. 

Client or Repository Station. The Repositories 3. 4. 5. and 6 provide visibility into 

Un-packager: This is a Helper Application system that RTES stored in the Repository database, which, in turn 

unbundles Repository Units. The Packager rues on the 45 provide users with the ability to re-use real-time embedded 

Repository Client or Repository Statioa Components (Components )or Application Frameworks 

Meta-data: This is data that is used to describe and (Frameworks) . The Component can be used as a basic 

characterize the contents of the Repository. For the MXP building block to create software products that can be 

Repository, the Meta-data is referred to as the body of the demonstrated and tested on the desktop. The Repository 

RC £?i t £?' VtUl Anributcs - » System further provides a high level of interactive value- 

CGI Program: This is a program that is launched by and added services to the user, thereby driving reusability of the 

runs oo the web server to provide specialized processing Repository Units to high levels. Such value added services 

a0 o° r ,^- CreatC a d y narajc HTML DocumcaL include code analysis, quality analysis, and the ability to 

Real-Time Embedded Components: This is a real-time provide '•playable*' RTES on the Repository Client or 

embedded software ( RTES) u nil that utilizes simulation 55 Repository Station. The Repository System further provides 

techniques, thereby having the ability to run on a multitude the necessary tools that allow software engineers to contrib- 

of Operating Environments, to provide cross platform ute objects to the Repository database for reuse by other 

services, system extensions, and operating system function- software engineers. 

ality The Components comprise test and analysis capabili- Several Repository Clients and Repository Stations may 

ues that allow the software engineer to fully characterize the eo access several Repositories simultaneously. In this context 

functionality of the Component and is designed to the level several Repository Clients and Repository Stations may 

analogous to an integrated circuit specification. The Com- login to several off-site Repositories or local Repositories 

ponents may be downloaded and executed on the desktop in simultaneously to access, and thereafter dispUy queried 

a stand alone configuration or can be incorporated into an results in much the same concept as PC's MACs, and UNIX 

Application specific framework and then executed. 65 workstations can all access Web servers on the Internet The 

AppUcauon Frameworks: This is a software unit that Repository Server then downloads the results on to the 

utilizes the simulation techniques, thereby having the ability Repository Clients and Repository Stations and, after further 
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instruction from the user, downloads ox check-out. Lc.. Attribute Value 

unpackag«. the requested Repository Unils-via FTP or Attribute Valerian 

HTTP mechanisms-to the user's desktop. The Repository ^ o 

System further provides platform iod^odcat ^a^"^^!?". 

Components and Frameworks from a collection of distrib- , fn . tS? L 23 ^ 1x11 " e 004 t0 * * c 
uted Repository Servers. If the Components and Framed f ° U ° W,ng rf «P««oiis: 
works are not corapaUble with the Client's desktop 
architecture— ie.. the software units were developed on a 
different operating platform— then simulation or transla- 
tions techniques, wherein translation software creates a 10 
virtual hardware environment in the target computer that 
simulates the functionality of each source machine, is uti- 
^ Preferably, other System defined Attributes that are either 
The Repository System is based on a parent<hild server required by the Repository System or are automatically 
hierarchy structure, though other Repository System struc- i5 assi 8 Dcd <V mc Repository Server include: Repository Unit 
tures such as Pecr-to-Peer and Client-Server are envisioned. Namc; Rc P ositor > r Unit Creator. Revision Number; Original 
Generally, the Repository Client accesses a Repository J^P 051 ^ Unit File Name; Repository Unit Type (e.g. 
Server which, in turn, searches for the Repository Units in Component. Framework, etc.); Repository Unit Password (if 
the "accessed" Repository database that match the attribute jcqu^ed); Repository Unit Text Description; Repository 
criterion. If there are no matches found in the "accessed" ™ \^<^y Words; Parent Repository Unit List (this facilitates 
Repository database, then the Repository Server searches ^^ C ?l VS? 1 ?' £ Rc P° $itor y Units); Child 
other unrestricted repository daubases until machine ^P°*itory Unit list (this facilitates the hierarchical structure 
Repository Units are JetecteJ. The ar^opnate tortc3 SLSS^T ^ R ^ il0 ^ Uttit "si (this 

fiKe?' 01 othcr ^ W** <* coUectionTof creator; mailing aldress oTcS ae^ 

rues, mc user then selects certain Repository Units from the M P™e of Repository Units; processor type7required MIPS- 

generated list and the Repository Server increments reuse ud required memory. It is important to recognize that the 

counts and then downloads the Component to the user's 4bove Repository System defined and user or System 

desktop The Repository System also downloads and pro- Administrator assigned Attributes are not intended to be 

vides information on Frameworks and other Repository exhaustive listing, and as such, a person of ordinary skill in 
Units. At this point the user may re-use the Repository Units 35 * e P^ 01 w ^ realize that other attributes are envi- 

or make any revisions thereto. sioned with the present invention. 

Access to Repository Units is achieved via searching 0 A dcUiied description of the search and downloading of 

based upon Attributes associated with the RTES stored in the !? epOS J torv Units based on Attribute searching follows. 

Repository. A Repository Unit. Component, or Framework Kc P°£ Uor y Server 

is described by one or more Attributes 23. By utilizing the ^ . * Repository Server is a multi-user server that provides 

defined Attributes 23 or designations, the user accesses the f* t ^f tus T f hlc software 10 u internetworked user coro- 

desired application for review, and for future modification or rUUnU ^ Thc Repository Server utilizes a commercial web 

other uses. Thus, Attributes 23 provide the classification and P"*"? sucb " N *«*P« or other software 

structuring information for the Repository Units. It is envi- SUm T P™** 1 * 1 " 10 P™*^ platform independent 

sioned that Attributes also track versions of Repository 45 J^A? * C ^f 0 "' R *P<*itory Server is inde- 

Units. Components, or Frameworks. This is accom^shed "archaWe, 

by assigning a Version Attribute to an already cxis tin s The Repository Servers further allow Repository Units to 

Repository Unit. It is preferred that unless otherwise £ searched, played, checked -in. checked- out. or purchased 

requested, an Attributes 23 search will always search for the .* Repository user. Repository Clients and Repository 

latest versions of the requested Coinponents-shieiding the * i^ZV^l WPp0rtCd * tbe Servers. The 

user from receiving duplicate informaUon for a (riven **eposuory Servers support groups of Repository users who 

Repository Unit. In alternate ernbodiments. Attributes may ? "% common Repository facilities. A Repository Station 

also comprise an Access List so as to limit access only users • " l Rcpositorv capabfliUes and also supports a seif- 

or user groups that appear on the Access Ust co ^, DO J sm ^ c uscr Repository not accessible to others. 

System defined Attributes 23 are described by name. illustrates a system level block diagram which 

format, value, and access parameters. These Attributes 23 ' e P re * CD ! s a . lo S icaI hierarchy of inter-nctworkcd 

are stored in a Repository Unit Descriptor File which f^" 0 ™*- *-e.. storage areas, which contain Repository 

includes the Attribute name and value, and are assigned by Vduablc 10 *™*°P** <* RTES. The Reposi- 

the Repository System at Repository Unit check-in Addi- . ?. aodUarc multi-«scr servers that provide 

dona! Attributes 23 may be defined and assigned by the user « " toreusable software to an internetworked user cora- 

and further associated with a particular Repository Unit ' U"^* Servers 7. 10. and 12 are accessed 

The Attributes 23 are utilized by the Repository Search t£ ^p 0 "?" 7 °* ntt 8 " d 9 Md Repository Station 11. 

Engine and by the user Search Templates to find Repository CUcfltJ » ">d 9 and Repository Station 11 

Units in the Repository. It is preferred that the Attrfoutes 23 Repository databases where the 

are defined with the following characteristics- Repository Units meeting the requirements of a particular 

Attribute Name (character string 256 characters or less) " ^L'"^' , ScV , Cfal Clients and Repository 

Attribute Format (string, integef. date, currency ^ g35S. ™" * ^ <* 
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Thus, the Repository System supports multiple users. the request for the HTML document that contains the 

using Repository Clients simultaneously logged into mul- searching program to the Shadow Server 13. The Shadow 

tiple Repository Servers. The Repository Clients can be Server 13 then executes the appropriate search utilizing 

located anywhere in the internetwork, such as a Local Area index files associated with the Repository Units. Repository 

Network (LAN), on distributed networked LANs, on dis- 5 Server 12 keeps its Shadow Server 13 and Shadow Reposi- 

tributed LANs across the Internet, on distributed Wide Area tory 13a current by downloading its index files upon any 

Networks (WAN), on distributed Metropolitan Area Net- change, or on a specific schedule. In alternate embodiments 

works (MAN), or aoy combination of the above. In the a Shadow Server and Shadow Repository exists oo any 

preferred embodiment, the Repository System utilizes the Repository Server or Repository, respectively, in the Reposi- 
TCP/IP protocol suite for networking support and services, to tory System, 

The preferred embodiment also utilizes Internet Web Tech- Referring to FIG. 3 the user typically accesses the Reposi- 

nology for communication between Repository Servers. tory Server through a Repository interface preferably known 

Repository Clients, and Repository Stations. as a login page 14. The login page 14 is preferably estab- 

Thc Repository Servers 7. 1*. and 12 comprise the Ushed on a user interface Repository System based on web 
following components in the preferred embodiment: is pages and a windows or compatible program. It is also 

Web Server Package (protocols HTTP/TCP/IP. FTP/TCP/ envisioned that login may occur without the aid of web 

IP. etc.) technology. In the preferred embodiment the web pages are 

Windows NT Version 3.51 or greater utilized by the Repository Server 7. The web pages are 

Security Package dynamically created and are completely interactive with 

„ . _ Jr 3 . „, , ^ 20 multimedia capabilities. The user's desklop utilizes a Win- 

Reposnory Entry and Introduction Web Pages dows or compatible program for viewing anyTwoioaded 

Repository CGI/server API Programs for Repository information received from the Repository Server 7. The user 

Access and/or Administration uses the Windows program for such purposes as Repository 

Repository Search Engine Unit Packaging. Application Playing, and Repository Unit 

FTP Server Analysis Tools to Annotate Checked-in 23 Un-paclcaging. 

Repository Units ^ Repository login page 14 comprises a login name IS 

Hard Drives for Storage of Repository Units and Reposi- f? d * P* 55 * 0 ** identifier 16. The session password 

tory Meta-data identifier 16 is used to track the user through the Repository 

Networked Access Software w Sa ""f D U thc " $cr atlera P ts 10 accc " a 

n,t a k., rw. „.... ... /c ,™ x 30 Felted Repository screen, the session is automatically 

Database Program Utilization (SQL) tenninated. The termination procedure protects the user 
CompUer/Unkcr/Loader Tools for building check-in from intercepting the session password identifier, thus pro- 
source code Repository Units hibiting the user from navigating to other prohibited screens. 
Other alternative embodiments also clearly exist For A timeout session for user inactivity or access to a wrong 
example, the present invention may also be implemented on 35 screen is also envisioned as part of the present invention. 
UNIX-based DEC. HP platforms or others that may occur. The login name 15 and a session password identifier 16 
The networked access software allows the user to access are the first line of security defenses. For added security 
and search a multitude of off-site or local on-site Repository access to individual Repository Units such as. Components 
Servers simultaneously. However, it is possible for a user Frameworks, or other objects are controlled through an 
with the appropriate permission to search multiple Reposi- 40 object access list which creates a "security code". This 
tones or to be restricted to only certain Repositories. Access access list is inspected when the user attempts to access the 
is restricted generally without the proper login name and Repository Unit Components, including Frameworks, or 
password identifier. The Repository Search Engine also aids other objects. The security code is carried throughout' thc 
the software engineer in finding Components. Frameworks. session through hidden variables in a dynamically created 
and other objects on the distributed Repository Servers. 43 HTML which is generated from thc CGI-WTN programs. It 
The Repository Servers 7. 10, and 12 are completely is preferred that all programs for creating dynamic Reposi- 
contained within a company's local internetwork or distrib- tory web pages are stored in the CGI-WTN directory In other 
uted across a global Internet Users with appropriate access ernbodiments, the Web Server may use other CGI mecha- 
permission have the ability to access all known Repositories nisms such as. CGI-DOS. or mechanisms such as JAVA or 
within the system from a single entry point and are search- 30 JAVA script. 

able by a single user with one search command. The The Repository System supports access levels of Browse 

Repository Server is capable of supporting numerous user Access. Check-out Access, and Adroinistrative Access 

names and numerous distributed Repositories simulta- Unauthorized access attempts are logged into a special audit 

0600 file for later resolution by a user or a security administrator 

In alternate embodiments, all Repository Servers in the 33 with the appropriate privfleges 

network system have rules that allow them to access and To further add to the security of the system, Repository 

search any other Repository database or deny access to the Units are not accessible through a direct URL. or other web 

search as required The Repository databases may also be page pointers and may be encrypted. The encrypted Reposi- 

encrypted so that the Repository Clients are denied access to tory Units are only accessible through the windows CCI- 

the Repository databases via encrypdon or password iden- 60 WIN program, thus, permitting only logged-in users who 

!P . „ . _ have navigated to the appropriate check-out screen to have 

Shadow Server 13 contains an index of Shadow Reposi- access thereto. In an alternate ernbodiment. a secure socket 

tory 13a of the contents of Repository Server 12 and is layer is provided for additional measures of security 

uitended to provide searching capabilities only. Shadow between the Repository Client and the Repository Server. In 

Server 13 performs the search of the Shadow Repository 13a 63 this mode, a private key is issued to the Repository Client 

mat Repository Server 12 would perform if it was not and the ReposUory Server, wherein the key is Utilized for all 

"bottle-necked. Logic in the Repository Server 12 redirects transmissions over the TCP socket layer. 
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templates to semi-automate sWch« aod <UspUy «Slts hi Zl^" ^TT" 5 ' °' ^ My rcvi ' 

user cootrollcd environment by employing System < ^^^^ B ^^^ UMa91 ^^ 
Attributes, The templates allow the user to construct sets of s<*«^ simulation techniques as described above, 

rules that permit the search to be targeted to reach specific "l^ 4 °* coursc process is directed towards a 

Repository Units. The user has access to all Attributestbat 5 J >caAc Inject goal by any Repository Client or Repository 
are within the users security limits. Server as fully described above. 

Referring to FIG. 4 a Repository Search Template 17 is For example, using the alternate example above the user 
shown which is based on user assigned and system defined 10 ^ scarch for Repository Units that have characteristics 
Attributes assigned to the Repository Unit at check-in. The "sodated with M aVpc=Software)". "(SubType-Utility)". 
Search Template 17 provides the user with a quick and "(C^eationDate>^/5/95).• , To search the Repository 

organized method for performing Repository searches based Server for the requested Repository Units, the user enters 
on the stored attributes. The Attributes allow for flexible Attributes "Software". "Utility**, and "created subsequent to 
charaacrizaUon of the Repository Units-e,g.. the abiliryto 13 6/5/95" into the Attribute Search Expression Dialog Box 19 
fully characterize a Repository Unit from a technical. <*• alternative, "dicidng" on the apprciwiatc Attribute 
quality, business, and documentation stand point. Initially. 23 in the Frequently Used Attributes Interactive Display 24 
the Searching Template prompts the user for a new template in we Search Templates 17. 25 or 27 and entering a new user 
name 18. Attribute Search Expression 19. Text Search String template name 18 as described above. The user can specify 
20. and a Binary Scarch String 21. The user does not have 20 "» Skater which Repository Units are required by 
to include all information requested by the Repository defining a Text Siring 2$ or adding further Operands 22 to 
Search Template 17; however, it is preferred that the user toe Attribute Search Expression 19. The addition of search 
include the new user template name 18 and at least one of Operands 22 expands or narrows the user's search depend- 
tbe other requested category information— i.e.. Attribute in 8 00 foe user's search intentions. 
Search Expression 19. Text Search String 20. or a Binary 25 Referring to FIG. 6. template 27 allows searching by 
Scarch String 21. The new user template name 18 identifies pre-defined templates which are assigned to specific users 
the search template 17 in the user's individual Search ^ interface of the templates hides the complexity of the 
Template Repository. The Search Templates 17 and 2S (as Attribute 19 expression that defines the search criterion, 
referred to in FIG. 5) are able to be utilized during subse- Otha examples of searching templates include Text Pattern 
quent Repository searches. 30 Search Templates in which text based Repository Units are 

The Repository Search Template 17 also includes a list of searchable using key words and phrases. There are no 
Attributes displayed in the Frequently Used Attribute Inter- practical limits to the number of templates that the user may 
active Display 23. and a list of Attribute Operands 22. FIG. define. 7 
5 shows a complete Attribute List 26 as partially shown. The Referring to FIG. 7 a Display Template Construction 
complete Attribute list contains a list of all known user 33 Form 28 is shown. The Display Template Construction Form 
accessible Attributes 23 in the system. These Attributes 23 28 S^^es the user in the construction of a custom display 
are user assigned or Repository generated and are stored in template which allows the user to examine scarch results in 
a Repository Unit Descriptor File. a user friendly environment. Alternate display template 

An illustrative example of a Search Template for a soft- constructions are envisiooed thereby allowing the individual 
ware engineer user may be as follows: 40 user to construct any number of templates that are user 

friendly to that user. 

•fcmpUteN^Wcuu^tiiiiie, ^ om J** 1 ** Templates formed from the Display 

Attribu* Ex,™***: oypc^ftw^^fsubTyp^utiiity) Template Construction Form 28 allow the user to display 

aa (Unfuiarf) aa (R^u^oum>io)aa . y rc ^ ucstcd "formation on the Display Template. i.e.. 

(CodeCocntDcaiJUii&orj) Display Form. The Display Templates further allows the 

"T^urcM^^eduau* ?' a A ]? "fP"*.** R*P™i»«y Units, and thereafter, down- 

Anribu* Expreuioo: fryiarfofrww) && {ScbTVr^UiiliM ™ , 4r p0SlU * y UaUs * U me Referred embodiment, the 

Display Templates are HTML formatted text files that com* 
— . prise Attribute 23 and attribute value place holder units that 

^^ a ^flT v ^ZTu £wL d " IZ^uTZ^*^ rcsults « ,ound • 
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displayed in a "Unit Display Page" 65. If ">=NUM" 66 Repositocy-CD Access Software 

(greater thao or equal to a user or System defined Dumber) Conipita/UiJctitoader Tools for building checked-ln 

" * > "ftT? " ^1 2^*?*? R V SU ' X l V f «* source code Repository Units 

"/p^, r S ,T ^ yC iI^ ^ y ,^r'^ <:USt Hd f» Application are discussed ^greater detail coo- 

at Repository Units to be rc- sorted by Attribute 23 each time 5 -,_ M H„„,-%T t t. d ri- . ... . 

an AV^utc is "clicked" These lines are implemented in 5 n ' ^ ^ ^ yS " " dacuuioiL 

embedded formi so that when a line is "clicked", a requested TV^T* ... D • n ■ 

Repository Unit is displayed in the "Unix Display Page" 65. Users access Repository Servers using Repository 

Searching bints 67 are provided when there are greater than CUcDt $aftw *»- Thc Repository dieot comprises a Reposi- 

a predefined number of Repository Units listed When the toiy acccss sofhvirc Ict tot provides the user with a 

user performs a search using Attributes 23 that are invalid or 10 set of capabilities to interact with the Repository Server, 

have permission restrictions, an error message 68 is dis- ^° * e preferred embodiment. Repository Client software 

played on the "Unit Display Page" 65 and the requested includes: 

search is not initiated. Web Browser Software 

Once the Repository Unit is checked-out thc repository Other means to simultaneously access multi media cross 

tools create a purchase record for the appropriate billing 13 platform information 

account and updates me re-use count in toe Repository Local j^ tQcizl jrforrnation Web Pages 

database as well as the appropriate informaUon concerning e . . * ' TT " . - 

the re-user. The Repository Server also includes other Simulated or actual Operating Environment For PC 
administrative access and functions, including amongst Simulated or actual Development Environment for Win- 
others, adding and deleting users, updating system files such 20 dows 

as password and access lists, completing the check-in pro- Simulated or actual Applications Environment 

cess for new Repository Units, as well as checking security MXP Application Player — Helper Application 

logs and resolving security issues. Users with administrative MXP Application Packager Used in Check in — Web 

access via appropriate permission can elect to produce based Helper Application 

reports or search a company for employees with specific 25 MXP Repository Unit Un-packager Used in Check-out 

skills. Further, corporate accounting departments can utilize Web based Helper Application 

the Repository for generating billing information and deter- Comrxlcr/Unker/Loadcr Tools for building checked-out 

niining the asset value of the Repository itself. source code Repository Units 

The above is only a representative example of adminis- The Repository Client and Repository Station contain 

trative functions utilizing the Repository, and as such, other 30 Helper Applications that provide enhanced capabilities for 

ernb<>diracnts and administrative functions are envisioned the Repository Client and Repository Station. Referring to 

hereto. As an example of alternate ernbodiments the present FIG. 9 the preferred embodiment separates these applica- 

invention can be used as an effective staff management tool. Uoos into three distinct categories: AppUcation Player 51, 

such as determining engineering capabilities— i.e.. object Repository Unit Packager 52. and Repository Unit 

creation and deposit within the MXP Repository-or for 35 Un-packager 53. Alternate enibodimcnts. including other 

system diagnostic capabilities. Helper AppUcation categories, are also envisioned The 

Repository Station AppUcation Player 51 preferably provides the following 

Referring again to FIG. 2. the Repository Station 11 capabilities: 

STi? £ UtDl CapabmUw and 1 an $Ct PUvs Component Repository Units that are downloaded 

of tools that allows the user to manage a local Repository. 40 frora ^ Repository 51fl (thcsc m MXP compliant 

such as the local disk Repositories 3. or a technology- software units) 

specific Repository CD 4. Thc Repository Station U pro- ^ Framcworks ^ ue dowaloadc4 from fte Rcposi . 

preferably with the limitation of functions to the single 45 . , /vppucauon oie 

independent Repositories 3 and 4 or other similar Repository "g* RcpoSltOC > UmU * at m Demonstration Modules 

storage areas. The Repository Station 11 Repositories are ~~ „ tI . M r tJ 

independentiy searchable-4.e.. thc ReposUorTserver 10 , ,?* " "^^.V 0 * p ***g« « preferably provides tbe 

does not have access to the Repository data or «^ties: 

raeta-data— utilizing Search Templates 17. 25 or 27 and 50 WiDdow5 Helper Application that allows the user to select 

Display Templates 28. ^ Wcs to combined into a Repository Unit 52a 

It is preferred that the Repository Station 11 or similar Allows the user to assign Attributes to the Repository 

station, include the following elements: Un ^ 4 

Web Browser Software Cre ates a package that can be transferred via FTP or 

Major Portions of thc Web Server Software for Searching 35 HTTP t0 ^ Repository Server for incorporation into 

Local Repositories Repository 52c 

Tutorial Information Web Pages ^ ^P 0 ^ Unit Un-packager 53o preferably 

Simulated or actual Operating Environment for PC T, &c J 0 " owb 8 a P^ m « : 

SimuUted or actual Development Environment for Win- „ 'ts^d^ ^ * 

SinuTteo or actual Action Environment "T^cT^L^^ ™ 

Application ^"Helper AppUcation Thc Repository Oient or Repository Station does not 

Repository Unit Packager Used in Check-in— Helper require any special hardware: however, it is preferred that 

Application M ^ e Repository oj cnt ^ Repository Station have multi. 

Repository Un-packager Used in Check-out— Helper media capabilities and web browser software packages that 

A PP UcatioD are configured with the appropriate Helper AppUcation. 
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and visibility of RTES. This capability is provided by present invention. 

allowing a multitude of different file types to be utilized in the Repository Units are further characterized using 

describing. demonstrating, or providing support for a single 5 analysis tools (software analysis). The analysis tools are 

or groups of files containing information about RTES. This sUrt ed when the RTES is initially cfaeefced-in to the Reposi- 

allows the user to create a multimedia presentation of the Iorv Server. These tools allow the user to associate fixed and 

RTES which includes an interactive demonstration. uscr defined Attributes to the RTES when the user checks 

The Repository System organizes and processes ReposJ- software into Repository, as well as creating a set of standard 

tory files as Repository Units. In the preferred embodiment 10 ? uaiit y index Attributes. The user also has the ability to 

the Repository Units are composed of the following files* inc *ude a desktop demonstration executable with the re-used 

Software Source FUes such as C. C++. Basic, and Fortran ^ ftwarc * <*eck-in or later, to be downloaded and run by 

A grc, P of axe Source Files that make up a utility *1«S^ which allow the 

h "n^^^ B ^ Tf ? a COdc ^ , ^onofmTa^^ 

load utility, or a checlcsum utility 15 ^ c Rcp0 sitory Units also allow the adoTon rfiS 

A group of Software Source Files that make up a sub- attributes which include the capability of tracking e-mail 

system such as a Device Driver, a signaling Software threads or other problem report threads relating to any 

module, a Communication Interface, or a Fax Decode particular Repository Unit, or be annotated with business 

Engine related attributes such as development cost and sales price. 

A group of Software Source FUes that make up a complete 20 Thc 0"*% Attributes also track revisions of the Repository 

system such as a ATM switch, an Internet Router, or a UniU wilnio thc Repository, view the particular Repository 

V34 Modem ' Units without having to access or display any prior 

lest Software such as packet generation software load rcvis j oos - *» wclJ « support multimedia capabilities and 

tester software, or device simulation code * SUpp,y sccunty t0 Rc P<«itory Units. Once the software 

Project make files which are used to build a software set * a "f 1 ^ ? _USC il U 10 ^ 

c an Lu ~ ™ IZT, software set and a record of such download is then generated 

Doamentation FUes from packages such as Frarnemaker. business, and documentation perspective. Thc Repository 
MS Word, or WordPerfect Units further have the capabiliUeTof contaimnTwhole 

Picture FUes that contain Drawings. Network Displays. projects. Components, and Frameworks. 
Finite State Machines, or Data Description Diagrams As mentioned previously, the Repository Search Template 

A complete Project that contains any combination of the 33 17 includes a list of Attributes 23 and Attribute Operands 22. 
above file types These Attributes 23 are user assigned or Repository gener- 

One of ordinary skUl in the art of the present invention atcd are stored in a Component Descriptor FUe. The 
will appreciate that other files can be composed to form Search Template 17 is implemented as a BOOLEAN expres- 
othcr Repository Units that provide additional information $ion of Attributes 23 which is evaluated against each Reposi- 
about the RTES stored in the repository. Ii will also be 40 torv ' $ acred components to determine when a desired 
apparent to oae of ordinary skUl in the art of the present Repository Unit is identified. It is preferred that the 
invention that the above individual file Lists also include Attributes 23 be constructed into BOOLEAN expressions 
other equivalent components. For example Documentation usin 8 ^ existence of the Attribute 23 in association with the 
FUes from packages such as Framemaker. MS Word, or Repository Units, or in the alternaUvc, as a comparison of 
WordPerfect also include, amongst others. QuattroPro. Pro- 4S ^ VaJue associated with a given Attribute 23 assigned to a 
fessional Writer, and OfficeWriter. Repository Unit. In the preferred embodiment, the BOOL- 

Repository Units also contain Attachments that provide EAN expressions. i.e.. the Ust of Attribute Operands 22 
current information to static files that are stored in the include, but are not limited, to the following expressions- 
Repository. The preferred embodiment utilizes the following 

attachments: 50 I and I or I n ot I feoL I les I lB6 I gtr | cm cf] 

E-mail Threads so that the users can continually assist 

other users concerning Repository Units 
Newsgroups (Internet style) such as a Problem Report J Vh 5 rc " AND " i$ a "AND" operation; '*OR w is a 

Group, a Users Group, or a Special Interest Group loglc ^ operation; "NOT' is a logical "NOT" opera- 
Expert Quality Ratings so that particular software spe- 55 U ° D ' ." E Q L ~ is 40 arithmetic equals operation to compare 

cialist can inform future re-users of the RTES of the T?, ^ **** typCS * ic> * itring to $trin& ' integer to integer. 

level of quality that can be expected from the Reposi- ^ !???? * ^ va1uc of this operation is a 

tory Unit ^ BOOLEAN TRUE or FALSE); "LES* is an arithmetic less 

Browse Count to record how may times the Repository ^ °P cr f on l?™*"* ^ <>au types (the result of this 

Unit was browsed a particular ReporitorV u^oTa * * I™ " FALSE): W " » 

combination of several Repository users arunmeoc less man or equal operation to compare two data 

Re-use Count to record how many times the Repository r^^^l^f '* * B00 }^ ™* <* 

Unit was checked out for re-use ^ y rAL&E), 'GTR 1$ an arithmetic greater than operation to 

Purchase Count and Amount to record how many time a „ ^SSIT^^F^^^ 
Particular Repositorv Uoit was nurrh*^ * n AlLl IKUK FALSE >' ^ E Q i* an anthmetic 

purchase prici purchased, and the greater than or equal operation to compare two data types 

(the result of this operation is a BOOLEAN TRUE or 
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FALSE); and "SUBSTR" is a left operand test string that is with visibility into attribute search results, multimedia 

a sub-string of the right operand substring. Arithmetic presentations, and product demonstrations. Customers 78 

equivalents of the above may also be utilized — e.g.. is arc further able to check-in search criterion to the KTES 

equivalent to "LES." Additionally, any combination of the Repository 70.72. This allows Customers 78 to purchase 

above Operands 22 can be utilized to facilitate other user 5 RTES software products. Again to access the Repository, 

defined Repository searches. It is preferred, however, that and check-in and check-out Components or Frameworks, 

boolean expressions that contain comparisons of the Value ^ c proper protocol as enumerated above must be satisfied, 

of an Attribute 23 conform to the Attribute's 23 format as LastJ y- Product Marketing Groups 82 and other corporate 

well. divisions 84. 86 also have access to the Repository system. 

Additional analysis information contained in the Compo- to ? ^ in$taDCC ix i$ preferred that the Product Marketing 

nents and Frameworks include Operating System Call Gro V ps 82 ?™ F™** with visibility into attribute search 

Return Checking. Operating System Call Utilization. Sys- T ^ multimcdia presentations, schedules, and product 

tem Resource LUilkaUon. L Memory Space Calculation. ^^TTT Product Marketing Groups 82 

Embedded source code analysis inWuo^des ou£ ^ multimedia mar- 

. . . / . * .Tl , J . keting presentations, product demonstrations, and attribute 

description, comment to code rauo. like-word file key-word i 5 search aiterion. Alternate embodiments wth regard to 

file, complexity analysts. LTNT results, and software line chcc king-in and checking-out of CompooenVand 

™ Frameworks, and other information from the PTES Reposi- 

How to Use . tory are also envisioned with regard to the product devcl- 

Refcmng to FIG. 10. a RTES Repository (Repositories) opmeut groups 74.76. customers 78. technology partners 80 
70. 72 internetworked to product development groups 74. 20 and corporate divisions 82. 84. 86. 

76. customers 78. technology partners 80 and corporate When a user desires to fully evaluate a RTES module 

divisions, such as marketing 82. product management 84. stored in the Repository of the present invention, the user is 

and accounting departments 86. is shown. As previously provided with the capability of executing the software 

stated the Repository comprises in -house server or local disk retrieved from the repository and observing the character- 

Repositories 3. Repository technology-specific CD Reposi- 25 istics of the RTES module while in operation. The user must 

tories 4. third party Repositories 5 accessed via the Internet also have the ability to vary the configuration parameters or 

or other internetworked systems, other internal off-site cor- input data so that the KTES module under evaluation can be 

porate Repositories 6 accessed via the Internet or other fully characterized for the proposed application. This is 

internetworked system, or Stand-alone Repository Systems. accomplished by an RTES application player. This RTES 

In the preferred embodiment, the product development 30 Repository application player capability allows the user to 

groups 74. 76 access the RTES Repository 70. 72 via the view the RTES module stored in the Repository and is 

Repository Server (not shown), which, after several steps as instrumental in promoting reuse. Since RTES modules can 

enumerated above, are able to download or check-out. i.e.. be exercised by a user and then suitability for reuse assessed, 

unpackage. the requested Repository Units— via FTP or Referring to FIG. 11. an example of such capability is 

HTTP mechanisms — to the development group 74. 76 user's 35 illustrated with the Repository contents for a balanced 

desktop. In particular, the product development groups 74. binary tree utility This type of software utility typically runs 

76 are provided with visibility into RTES stored in the in ao embedded environment where it is utilized by various 

Repository database, and more particularly, reused RTES types of software sub-systems such as Protocol Software or 

Components and Frameworks, attribute search results, mui- embedded database applications. The creator of a software 

tiroedia presentations, schedules, product, demonstrations. <o module like the balanced binary tree utility has the capabil- 

Repository Unit E-mail threads, and Repository Unit prob- ity of Including with the Repository Unit one or more 

lem threads. The product development groups 74. 76 are Desktop applications, such as a Windows or Unix 

further able to deposit, i.e.. check-in, units to the RTES application, to provide a graphical user interface (GUI). This 

Repository 70. 72, such as new KTES Components and would involve the creation of a Windows (or Unix) program 

Frameworks, attribute definitions, multimedia presentations, 45 shell that is built with the utility software to provide the 

schedules, product demonstrations. Repository Unit E-mail. mechanisms for data input and the display of results. The 

threads, and Repository Unit problem threads. This allows prospective re-user of the utility has the capability of down- 

for the development and re-use of new products, and new loading and executing this software on a desktop machine 

features within existing products. that matches one of the desktop applications associated with 

Technology partners 80 are also provided with visibility 50 the utility that is stored in the Repository (e.g. Windows 

into the RTES Components and Frameworks, wherein it is Desktop machine would download only Windows 

preferred that the technology partners 80 be provided with cxecutables). 

visibility into Repository Unit E-mail threads, and Reposi- It is not always possible for the creator of an embedded 

tory Unit problem threads, multimedia presentations. software module to create a desktop application with a GUL 

schedules, product demonstrations for integration purposes 55 though, because the user may not have the specific skills 

and integration tests. The technology partners 80 are able to required to write, for example, a Windows application The 

check-in attribute definitions, multimedia presentations. user also may not have development time scheduled for that 

schedules, pricing/cost attribute*, and Search criterion. This purpose. In order to account for this situation and still 

allows die technology partners 80 to perform Integration provide visibility, the MXP Repository System allows 

tests, which, in turn, allows for inter-operating software with 60 embedded software that is written to an API that conforms 

other technology partners. Of course the proper protocols for to Real-rime Embedded Operating System primitives (such 

both technology partners 80 and product development as MXP. PSOS. VxWorks) to be executed in an emulation 

poups 74. 76, as enumerated above, must be met when environment on the Repository Client. The Repository Cli- 

checkmg-in and checking out RTES. as well as accessing eat (and Repository Station) includes an env3ooment and 

(X T lI1 f %° Ut0n f C *' ^ v _ 65 ut &*y loads embedded software onto the Desktop and 

It ts further preferred that customers 78 have access to the allows it to be executed. This utility is referred to u the 

KTES Repository 70.72 as well. Customers 78 are provided RTES Application Player 
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from the RTK Repository. T*e RTES ApplicaUon Player the attributes of the Tt^^^^^^f^ 

^ f!™ L^L" fOT ^ ° S P 1 ^" "sociatcd g) the multimedia display means displaying the resuiis of 

witt, real-Ume embedded operating systems such as timing 5 the repository diem query made to L parenT reposi- 

aod synchronization, messagiog. task scheduling, and tory server, and 

memory management. The utility starts the embedded soft- h) a first communication link which joins the repository 

ware as if it is running in the embedded environment, and client and the parent repository server. 

allows the user to stimulate the embedded software through 2. The repository system of claim 1 wherein the parent 

its OS primiuves. For example, when the embedded soft- 10 repository server further comprises means for limiting 

ware includes an input message queue that a task in the acccss to the Parent repository server. 

embedded software utilizes, the MXP Application Player 3. The repository system of claim I wherein the repository 

assists the user in building a message and then allows the system comprises multiple satellite servers at different geo- 

uscr to inject that message on to the spedficd queue. The Sophie locations linked via second communication links to 

embedded software that is executing in the RTES Appiica- 15 thc P 31 " 11 repository server. 

tion Player may then read the message on that queue and 4 Thc repository system of claim 3 wherein thc parent 

perform its operations based on thc received message. The r £ posllory system comprises means for permitting acccss to 

RTES application monitors the embedded application from thcsc . sa f cUilc repository servers according to {reestablished 

its interface with thc OS primitives, and provides the user P *^^°.!!L 

with a graphical view of OS resource utilization and inter- 20 rutlz!^ ** ^r" 1 ? ^ 2 * e rc P osit0f >' 

action. The Application Player also includes simXtion displaying a search template, thc 
sup^rt for sZard intcrfac/s to devices su^as^" 

nicauon controllers, dual port RAMS flash 1 rn/i pn TXnT 

rs^t^saK^. 1 ? * sir- r - M - ^ ^ 

«^ « med ! WUS ° i ,* empl0yed by 46 Appli- embedded software based on^V^b^s 
STarT^ES ^S^S^ ^ ^ 30 «• -n»« "PO"^ astern o^rs^erao the search 

hanhJI^ ?T . Jr"^ Repo««*y 00 matching Urge. template allow, searching of the parcel repository server 

Je and M of rcaI - 50 a E^^^^r 1 **** ^ 

tory server having storage means; IS. The repository system of claim 1 wherein the reposi- 

b) at least one repository client having multimedia display torv clic nts have means to limit the acccss of a user to the 
means; 55 repository client 

c) means for generating a query to the parent repository , l ?' ^ rc P 0sitor y system of claim 15 wherein the access 
server, the query generating means resident on the ^^Qg means comprises a login name, a session password, 
repository client to search for attributes of real-time and a sc$sio ° termination procedure. 

embedded software stored on the parent repository 17, ^ rc P° $itor y system of daim 5 wherein the search 
server; 60 template permits searches selected from the group consisting 

d) real-time embedded software stored on the parent ? f binary Scarch string ' tcxt scardl frequency of use 
repository server storage means- y wor(k * ^ Phases- user definable attributes. 

e, aaributes associated with the real-time einbedded soft- xJ^i^^Z'*™ * **** * WhexdB "* 5Carch 
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20. The repository system of claim 19 further comprising terminal, the search template comprising potential attributes 
download means so that real-time embedded software that of the desired real-time embedded software, 

meets search criteria entered on the search template is 30. The method of claim 24 farther comprising esublish- 

downloaded to the repository client ing a local database of real-time embedded software 

21. The repository system of claim 1 further comprising 3 attributes. 

repository tools. 31 The method of claim 30 further comprising searching 

22. The repository system of claim 21 wherein the reposi- the local database based upon the real-time embedded 
tory tools comprise message creation tools, adding and software attributes. 

deleting user tools, updated password tools, purchase record 31 The method of claim 30 wherein searching the local 

creation tools, check-in process tools, security log tools, and to database further comprises completing a template of the 

bill creation tools. real-time embedded software attributes. 

23. The repository system of claim 14 wherein the reposi- 33. The method of claim 24 wherein storing the real-time 
tory further comprises index creation means and means for embedded software further comprises checking in the real- 
downloading the index to the shadow repository. time embedded software by completing attributes relating to 

24. A method for creating a repository of real-time embed- 1 5 the real-time embedded software. 

ded software comprising: 34. The method of claim 24 wherein characterizing the 
a j storing the real-lime embedded software in a first real-time embedded software by at least one attribute corn- 
repository server; prises dynamically calculating attributes of the real-time 
bj characterizing the real-time embedded software by at embedded software being checked- in. 
least one attribute; 20 35, Thc n»etbod of claim 24 wherein retrieving the reaj- 

c) creating a query od a repository client lo the repository ^ CmbC<Wcd *» ** *« repository server further 
server basil on desired *e real-time embeddWsoft- COmptlSCS «WH*«* ** embedded soft- 
ware attributes; wa f^' 

*\ a i . . - , 36. The method of claim 24 wherein characterizing the 

d) retrieving the real-time embedded software from the M tesii .timt embedded software further comprises creating a 
first repository server; and repository access list based on the queries generated by Ae 

e) displaying the retrieved real-time embedded software repository clients, 

on the repository client. 37. The method of claim 24 further comprising creating a 

25. The method of claim 24 wherein the first repository is repository index and a shadow database capable of rcspood- 
selected from the group consisting of in-house server 30 ing to queries of repository clients. 

repositories, local disk repositories, repository technology- 38. The method of claim 24 further comprising limiting 

specific CD repositories, third party repositories accessed access to repository clients by access limiting means, 

via the Internet, third party repositories accessed via an 39. The method of claim 38 wherein the access limiting 

internerworked systems, internal off- site corporate reposito- means comprises a login name, a session password, and a 

rics accessed via the Internet or other intemetworked 35 session termination procedure. 

system, and stand-alone repository systems. 40. The method of claim 29 wherein the search template 

26. The method of dairn 24 further comprising limiting permits searches based on the group comprising binary 
access to the repository server. search strings, text search strings, frequency of use of key 

27. The method of claim 24 further comprising linking at words, key phrases and user definable attributes. 

least a second repository server to the first repository server 40 41. The method of claim 24 wherein creating a query on 

and searching the second repository server based on the the repository client involves creating a user defined search 

query created by the repository client template, 

28. The method of claim 24 further comprising permitting 42. The method of claim 41 wherein the user defined 
access to satellite repository servers according to preestab- search template is displayed on a repository client display 
lished permissions. 45 means. 

29. The method of claim 24 wherein creating a query 

further comprises creating a search template on a desktop * * * » * 
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